3GPP is working with requirements and architecture for Machine Type Communication (MTC). MTC security aspects are considered in TR 33.868 Rel-12. The endpoints of security and corresponding security mechanisms are shown in FIG. 1 of section 4 of TR 33.868 Rel-12.
Two possible security endpoints of security are a client device such as a User Equipment (UE) and a MTC Server/Application. These represent a so called “Secure Connection”, which is intended to be application layer security between the UE and MTC Server/Application. It is currently specified that the 3GPP operator may assist with key management for the Secure Connection, e.g. with the help of GBA (Generic Bootstrapping Architecture) [TS 33.220 sections 1-5], but otherwise the Secure Connection is assumed to be transparent to the 3GPP network. In principle, any security mechanisms can be used for the Secure Connection.
In the MTC architecture for Rel-12, a new use case for protecting the MTC device trigger from the SCS network server to the UE has been identified. Using Generic Push Layer (GPL) for end-to-end protection of the MTC device trigger was seen as favourable.
GBA is an authentication infrastructure. It includes a 3GPP Authentication Centre (AuC), a Universal Subscriber Identity Module (USIM) or an IP Multimedia Services Identity Module (ISIM), and the 3GPP Authentication and Key Agreement (AKA) protocol run between them, and is a very valuable asset of 3GPP operators. It was recognized in 3GPP Rel-6 that this infrastructure could be leveraged to enable application functions in the network and on the user side to establish shared keys. Therefore 3GPP provided the ‘bootstrapping of application security’ to authenticate the subscriber by defining a GBA based on AKA protocol in TS 33.220. There was a need seen at that time for several applications such as Multimedia Broadcast Multicast Service (MBMS), subscriber certificate distribution etc. This list of applications has expanded since then.
A simple GBA flow between a UE 1, a Bootstrapping Server Function (BSF) 2 and a Home Subscriber Server (HSS) or Home Location Register (HLR) 3 is illustrated in FIG. 1. A Bootstrapping Transaction Identifier (B-TID) value is generated by the BSF in a Network Access Identifier (NAI) format by taking a base64 encoded RAND value from step A3, and the BSF server name, i.e. base64encode(RAND)@BSF_servers_domain_name. The B-TID provided by the BSF 2 to the UE 1 identifies the established shared key Ks. The UE 1 uses the B-TID in all its communication with one or more Network Application Functions (NAFs) as follows. The shared key Ks is created by a concatenation of CK and IK (Ks=CK∥IK) in the UE 1 and the BSF 2.
3GPP defined the Generic Authentication Architecture (GAA). The adoption of GAA by other standardization bodies showed that some services cannot make the assumption that the UE 1 always has the possibility to connect to the BSF 2 or that the UE 1 for different reasons has not performed a bootstrapping procedure directly with the BSF 2. 3GPP therefore introduced and specified a GBA Push Function.
GBA-push is a mechanism to bootstrap the security between a NAF 4 and a UE 1, without forcing the UE 1 to contact the BSF 2 to initiate the bootstrapping. GBA-Push is closely related to and builds upon GBA as specified in TS 33.220. FIG. 2 illustrates a simple network architecture for GBA-push.
An exemplary use case is that a NAF 4 initiates establishment of a shared Security Association (SA), a NAF SA, between itself and the UE 1. This is done by the NAF 4 pushing all information, the so called GBA-Push-Info (GPI), needed for the UE 1 to set-up the SA. The key in this SA is a NAF-key and the GPI is requested from the BSF. The NAF-key is generated as defined in GBA, TS 33.220.
After the NAF SA establishment, the NAF 4 can send protected Push-messages to the UE 1. If a return channel exists, and if defined by a Ua application, the UE 1 can also use the established SA to protect response messages to the initiating NAF 4. The NAF SA is identified by downlink and uplink SA identifiers.
Furthermore, Generic Push Layer (GPL) was introduced in 3GPP Rel-9. GPL is a generic push layer that makes use of the GBA Push Function as specified in TS 33.223. The GPL specification in TS 33.224 includes a message format, cipher suites and processing model for a protocol to provide integrity and confidentiality protection of data sent between Push-NAFs and UEs. GPL assumes that keys and other SA parameters have been preinstalled in the Push-NAF 4 and UE 1 in the form of a NAF SA. GPL is a protection protocol that can be applied in a unidirectional or bidirectional fashion. The main purpose of GPL is to protect traffic pushed from a Push NAF to a UE.
It was expected that there would exist Push-NAF based services that rely on some form of per device session concept, and which would benefit from pushing more than one message based on the same security association to the UE 1. This required that GPL provided reply protection in addition to integrity protection (and possibly confidentiality protection) for several messages that are associated with each other (in contrast to only protect one single message). FIG. 3 depicts a usage scenario, where three push messages are delivered from the Push_NAF 4 to the UE 1 using a single security association.
A NAF 4 supporting and using GPL with a UE 1 needs to store at least one security association in downlink and one in uplink for each corresponding UE 1. A UE 1 supporting and using GPL needs to store at least one security association in downlink and one in uplink for each corresponding NAF 4.
The security association identifiers that have been specified in GBA Push TS 33.223, and which are inherited by GPL in TS 33.224 when TS 33.224 is used in conjunction with GBA Push in TS 33.223, to identify the security association used in uplink and downlink are the following:                Downlink SA identifier (DL_SA_ID): RAND@‘naf’        Uplink SA identifier (UL_SA_ID): P-TID (a unique value in the Push NAF 4).        
A new feature has been identified where the UE 1 is the initiator of the traffic between the UE 1 and the Push NAF 4. An example of this is where the UE 1 sends a payload in a Short Message Service (SMS) message protected by GPL to the push NAF 4. Since the UE 1 is the peer that initiates the traffic in this feature, the push NAF 4 may not yet have pushed down a NAF SA using GBA Push (TS 33.223) and neither has the push NAF 4 requested a NAF SA from the BSF 2 when the UEs GPL message arrives at the NAF 4.
The GPL specification in TS 33.224 does not support this use case, as it is based on the assumption that it is used in conjunction with the GBA Push specification in TS 33.223. One particular problem is that TS 33.223 describes that the UE 1 uses a Push Temporary Identifier (P-TID) in GPL as the identifier for the uplink (UL) security association. However, according to TS 33.223 the P-TID is an identifier that is supposed to be created by the push NAF 4. In the case when security associations are established with GBA (TS 33.220), it is not described how the push NAF 4 has allocated and assigned an uplink security association identifier to the UE 1, the UE 1 does not know what to use as an uplink security association identifier in the GPL message, and the Push NAF 4 does not know how to interpret the field. As a result GPL cannot be used in this example.
A further problem arises in the case where the push NAF 4 wants to use GPL, and wants to use an existing key from a normal GBA bootstrapping. Also in this case there will be problems related to the uplink security association identifier in GPL. In the current GBAPush specifications in TS 33.223, the P-TID (i.e. the uplink security association identifier) is integrity and confidentiality protected all the way from the BSF 2 to the UE 1 (it is included in the so called GBA-Push-Info (GPI)). Since the use case considered here does not send any GPI from the BSF 2 to the UE, there is again no uplink security association identifier provided to the UE 1. If the UE then needs to send a GPL message to the Push NAF, the uplink security association identifier is again amiss.
Another problem that needs to be considered is that in existing GPL specification in TS 33.224 it is assumed that the NAF 4 allocates the downlink security association identifier by taking the RAND received from BSF and uses it as the identifier of the down link security association in GPL for all downlink traffic protected by GPL to be sent to the UE 1. In TS 33.223 and TS 33.224 it is specified that the NAF 4 creates the downlink security association identifier as RAND@‘naf’. The UE 1 then has the RAND from the GPI Information received from the NAF 4 in GBA Push prior to receiving any downlink traffic protected by GPL from the NAF 4. The UE 1 next creates the downlink security association identifier in the same way as the NAF 4 as described above.
However, if no GPI Information has been sent down by the push NAF 4 to the UE 1 prior to the push NAF 4 wanting to use GPL, then the UE 1 and the push NAF 4 have not established security associations from GBA Push and have no agreement on what to use as downlink security association identifier as described above, accordingly. If the push NAF 4 instead wants to use an existing key from a normal GBA bootstrapping then the push NAF 4 and the UE 1 need to use the B-TID allocated by the BSF 2 in normal GBA in existing specification in TS 33.220 or a new identifier based on B-TID, in order to construct a new downlink security association identifier to be used in GPL. In TS 33.220 the BSF allocates the B-TID as follows:
B-TID: base64encode(RAND)@BSF_servers_domain_name.
There is no existing mechanism to allow a NAF 4 to securely communicate with a client device such as a UE 1 when no GPL security associations have been established between the NAF 4 and the UE 1.